Cryptographic algorithms are widely used for encryption and decryption of messages, authentication, digital signatures and identification. In the field of data security, there is a need for fast and secure encryption. This is why the AES (Advanced Encryption Standard) cipher has been designed and standardized to replace the DES (Data Encryption Standard) cipher. AES is a well known symmetric block cipher. Block ciphers operate on blocks of plaintext and ciphertext, usually of 64 or 128 bits length but sometimes longer. Stream ciphers are the other main type of cipher and operate on streams of plain text and cipher text 1 bit or byte (sometimes one word) at a time. There are modes of operation (notably the ECB, electronic code block) where a given block is encrypted to always the same ciphertext block. This is an issue which is solved by a more evolved mode of operations, e.g. CBC (cipher block chaining) where a chaining value is used to solve the 1-to-1 map.
AES is approved as an encryption standard by the U.S. Government. Unlike its predecessor DES (Data Encryption Standard), it is a substitution permutation network (SPN). AES is fast to execute in both computer software and hardware implementation, relatively easy to implement, and requires little memory. AES has a fixed block size of 128 bits and a key size of 128, 192 or 256 bits. Due to the fixed block size of 128 bits, AES operates on a 4×4 array of bytes. It uses key expansion and like most block ciphers a set of encryption and decryption rounds (iterations). Each round involves the same processes. Use of multiple rounds enhances security. Block ciphers of this type include in each round use of a substitution box (S-box). This operation provides non-linearity in the cipher and significantly enhances security.
Note that these block ciphers are symmetric ciphers, meaning the same key is used for encryption and decryption. As is typical in most modern ciphers, security rests with the (secret) key rather than the algorithm. The S-boxes accept an n-bit input and provide an m-bit output. The values of m and n vary with the cipher and the S-box itself. The input bits specify an entry in the S-box in a particular manner well known in the field.
Many encryption algorithms are primarily concerned with producing encrypted data that is resistant to decrypting by an attacker who can interact with the encryption algorithm only as a “Black Box” (input-output) model, and cannot observe internal workings of the algorithm or memory contents, etc due to lack of system access. The Black Box model is appropriate for applications where trusted parties control the computing systems for both encoding and decoding ciphered materials.
However, many applications of encryption do not allow for the assumption that an attacker cannot access internal workings of the algorithm. For example, encrypted digital media often needs to be decrypted on computing systems that are completely controlled by an adversary (attacker). There are many degrees to which the Black Box model can be relaxed. An extreme relaxation is called the “White Box” model. In a White Box model, it is presumed that an attacker has total access to the system performing an encryption, including being able to observe directly a state of memory, program execution, modifying an execution, etc. In such a model, an encryption key can be observed in or extracted from memory, and so ways to conceal operations indicative of a secret key are important.
Classically, software implementations of cryptographic building blocks are insecure in the White Box threat model where the attacker controls the execution process. The attacker can easily lift the secret key from memory by just observing the operations acting on the secret key. For example, the attacker can learn the secret key of an AES software implementation by observing the execution of the key schedule algorithm.
Hence there are two basic principles in the implementation of secure computer applications (software). The Black Box model implicitly supposes that the user does not have access to the computer code nor any cryptographic keys themselves. The computer code security is based on the tampering resistance over which the application is running, as this is typically the case with SmartCards. For the White Box model, it is assumed the (hostile) user has partially or fully access to the implemented code algorithms; including the cryptographic keys themselves. It is assumed the user can also become an attacker and can try to modify or duplicate the code since he has full access to it in a binary (object code) form. The White Box implementations are widely used (in particular) in content protection applications to protect e.g. audio and video content.
Software implementations of cryptographic building blocks are insecure in the White Box threat model where the attacker controls the computer execution process. The attacker can easily extract the (secret) key from the memory by just observing the operations acting on the secret key. For instance, the attacker can learn the secret key of an AES cipher software implementation by passively monitoring the execution of the key schedule algorithm. Also, the attacker could be able to retrieve partial cryptographic result and use it in another context (using in a standalone code, or injecting it in another program, as an example).
Content protection applications such as for audio and video data are one instance where it is desired to keep the attacker from finding the secret key even though the attacker has complete control of the execution process. The publication “White-Box Cryptography in an AES implementation” Lecture Notes in Computer Science Vol. 2595, Revised Papers from the 9th Annual International Workshop on Selected Areas in Cryptography pp. 250-270 (2002) by Chow et al. discloses implementations of AES that obscure the operations performed during AES by using table lookups (also referred to as TLUs) to obscure the secret key within the table lookups, and obscure intermediate state information that would otherwise be available in arithmetic implementations of AES. In the computer field, a table lookup table is an operation consisting of looking in a table (also called an array) at a given index position in the table.
Chow et al. (for his White Box implementation where the key is known at the computer code compilation time) uses 160 separate tables to implement the 11 AddRoundKey operations and 10 SubByte Operations (10 rounds, with 16 tables per round, where each table is for 1 byte of the 16 byte long—128 bit—AES block). These 160 tables embed a particular AES key, such that output from lookups involving these tables embeds data that would normally result from the AddRoundKey and SubByte operations of the AES algorithm, except that this data includes input/output permutations that make it more difficult to determine what parts of these tables represent round key information derived from the AES key. Chow et al. provide a construction of the AES algorithm for such White Box model. The security of this construction resides in the use of table lookups and masked data. The input and output mask applied to this data is never removed along the process. In this solution, there is a need for knowing the key value at the compilation time, or at least to be able to derive the tables from the original key in a secure environment.
The conventional implementation of a block cipher in the White Box model is carried out by creating a set of table lookups. Given a dedicated cipher key, the goal is to store in a table the results for all the possible input messages. This principle is applied for each basic operation of the block cipher. In the case of the AES cipher, these are the shiftRow, the add RoundKey, the subByte and the mixColumns operations.
Further, the publication “Cryptanalysis of a White Box AES Implementation” by Olivier Billet et al., in “Selected Areas in Cryptography 2004” (SAC 2004), pages 227-240 is a successful attack on a White Box cipher of the type described by Chow et al., indicating weaknesses in Chow et al.'s approach. Software implementations of cryptographic building blocks are thus insecure in the White Box threat model where the attacker controls the execution process. The attacker can easily lift the secret key from memory by just observing the operations acting on the secret key. For example, the attacker can learn the secret key of an AES software implementation by observing the execution of the key schedule algorithm.
Content protection applications are one instance where it is desired to keep the attacker from finding the (secret) cryptographic key even though the attacker has complete control of the execution process. The publication by Stanley Chow, Philip A. Eisen, Harold Johnson, Paul C. van Oorschot: White-Box Cryptography and an AES Implementation. Selected Areas in Cryptography 2002: 250-270 is another publication which gives a construction of the AES algorithm for such a White Box model. The security of this construction resides in the use of table lookups and masked data. The input and output mask applied to this data is never removed along the process. In this solution, there is a need to know the key value at the compilation time, or at least to be able to derive the tables from the original key in a secure environment.
However, the Chow et al. White Box solution does not solve all needs for block cipher operations. Indeed, the case where a cryptographic key is derived through a given process and thus unknown at the code compilation time is not provided for.
The security of Chow et al. resides in the use of table lookups and masked data. The input and output mask applied to this data is never removed during the process. In this solution, there is a need to know the key value at the compilation time, or at least to be able to derive the tables from the original key in a secure environment.